CI Commands

The following CI workflows run automatically on every push and pull request:

The following commands can be used by maintainers to trigger additional tests that require access to secrets:

Note: Only repository maintainers (OWNER association) can trigger /metaci commands. After commenting the command, a maintainer must also navigate to the Actions tab and approve the deployment to the graph-api-access environment before the jobs will run. See the approval guidelines for what to approve or reject.

Could I get some feedback? This is tackling my aforementioned feature request on supporting other hardware

gcm --backend=nvml --sink=stdout ...
healthchecks ... --backend=nvml --sink=stdout ...

this should be a full run of the cmd with the corresponding output for each

@luccabb the hardware backend works and the functionality works on my end with a gpu instance. let me know if you have any other feedback

@theap06 I meant you should add the real CLI call and outputs from it in the test plan from inside your env.

similar to what you did for #61

Done.

@luccabb could I get some feedback? I added the testing for HAL in the pr message.

@claude can you review this pr?

Claude Code is working…

I'll analyze this and get back to you.

View job run

@claude can you review this pr?

Claude finished @luccabb's task in 1m 52s —— View job

PR Review: add python accelerator HAL for multi-vendor backends

• Gather context and understand request
• Read CLAUDE.md for repo guidelines
• Read changed files
• Provide comprehensive review

Overall, this is a clean, well-structured HAL abstraction. The module layout, error hierarchy, Protocol-based interface, and test coverage are all solid. A few issues need to be addressed before merging.

Critical Issues

1. --backend option is accepted but never used

In both gcm/monitoring/cli/gcm.py:43 and gcm/health_checks/cli/health_checks.py:39, the backend parameter is immediately discarded:

def main(detach: bool, backend: str) -> None:
    _ = backend   # ← never forwarded anywhere

The option appears in --help and is validated by Click, but it does nothing. The new AcceleratorManager/NVMLBackend is never instantiated from the CLI path. The nvml_monitor subcommand still goes directly through the old DeviceTelemetryClient. Until this wiring is added, the HAL is not actually used at runtime. Fix this →

2. get_vbios_version() used to populate the model field — semantically wrong

In gcm/monitoring/accelerator/backends/nvml.py:92:

model = client.get_device_by_index(index).get_vbios_version()

get_vbios_version() returns a firmware version string (e.g. "90.00.38.00.09"), not the GPU model name (e.g. "A100 80GB"). The DeviceHandle.model field implies a human-readable hardware model. This should use get_name() or similar if available on the client. Fix this →

Minor Issues

3. NVMLBackend.close() does not close the underlying client

In gcm/monitoring/accelerator/backends/nvml.py:174-176:

def close(self) -> None:
    self._client = None   # ← just drops the reference; no shutdown call
    return None

If DeviceTelemetryClient holds resources (e.g. NVML context), this leaks them. The close should call self._client.close() (or equivalent) before clearing the reference. Fix this →

4. BackendOperationError stores cause redundantly

In gcm/monitoring/accelerator/errors.py:20-27, cause: Exception is stored as a dataclass field and set as the chained exception via raise ... from e at the call sites. This means the exception appears twice. The __str__ method also manually formats it. Consider dropping the explicit cause field and relying solely on Python's built-in exception chaining (__cause__).

5. NVMLBackend subclasses AcceleratorBackend (a Protocol)

In gcm/monitoring/accelerator/backends/nvml.py:51:

@dataclass
class NVMLBackend(AcceleratorBackend):

AcceleratorBackend is defined as a Protocol. You don't need to explicitly inherit from a Protocol to satisfy it — you just need to implement the methods. Subclassing a Protocol creates a coupling that isn't needed and is non-idiomatic. NVMLBackend should just be a plain class (or dataclass) that happens to implement all the AcceleratorBackend methods.

Observations / Non-blocking

• MetricRequest.include_process_info is ignored in read_metrics: The _request parameter in NVMLBackend.read_metrics is never read. If process info collection is planned, a TODO comment would clarify intent.
• probe() is called before enumerate_devices() in tests but not enforced: Nothing stops a caller from calling enumerate_devices() on an unprobed backend (the client will be lazily initialized, which may raise). A guard or documented contract would help.
• Test coverage is good — the 12 HAL unit tests cover normal operation, partial failures, missing library, fallback paths, manager lifecycle, and registry. The new integration tests in test_gcm.py gracefully handle no-GPU environments.
• README is clear and well-written — the lifecycle section and backend authoring guide are helpful.

Summary

The HAL design is solid and the tests are thorough. The main issue is that the --backend flag is not wired to the HAL — the new code is tested in isolation but not yet integrated into the runtime monitoring path, which undermines the core goal of the PR. The model field bug and close() resource leak should also be fixed. Happy to see this land once those are addressed.

@claude review my pr

@claude

Claude finished @luccabb's task in 1m 8s —— View job

PR Re-Review: add python accelerator HAL for multi-vendor backends

• Gather context
• Read changed files and CI diff
• Provide updated review

One Issue Blocking Merge

.github/workflows/gcm_python.yml deletes the Rust installation step that exists on main

The PR removes these 5 lines from main (around line 67):

      - name: Install Rust
        run: |
          curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
          cp -r $HOME/.cargo/bin/* $HOME/.cache/venv-ci/bin/

This step was added to main independently to fix a build dependency that requires Rust. It has nothing to do with this PR. Removing it here means merging this PR would silently break the Rust-dependent build on main.

The author's explanation ("reverted it since I removed the related code from this PR") suggests they added this step in their branch and are now reverting their own addition — but this step was already on main before this PR branched off. The diff is subtractive relative to main, not just undoing a change introduced in this branch.

Fix: Restore those 5 lines so the workflow file is identical to main. This PR should not touch .github/workflows/gcm_python.yml at all. Fix this →

Everything else from all prior reviews remains fixed. This is the only remaining change needed before merge.

@luccabb added back the rust dep

please address #86 (review)

addressed

@luccabb could i get some feedback on this pr

@luccabb it should be ready to merge

@luccabb will close this pr.